Intel® DMI 2.0 Service Provider (SP) SDK Version 1.0 for Novell NetWare* Release Notes

This SDK contains NetWare*-specific DMI information. It is intended both for developers of local DMI 2.0 applications (management application [MA] and component instrumentation [CI]) for NetWare 4.1x, and to complement the Intel DMI 2.0 Service Provider SDK for Win32*, enabling remote access from Win32 over ONC-RPC to managed NetWare nodes. For a full DMI 2.0 development environment, download the Intel DMI 2.0 Service Provider SDK for Win32 for the Win32 reference manual, the Intel DMI Explorer and the Intel DMI 2.0 SDK Development Tools.

This document contains information about the above product in these sections:

1. Release Contents
2. Target Environments
3. Technical Support Information
4. Installation Instructions
5. Operating Instructions
6. Product Release Notes

1. DMI 2.0 Service Provider for NetWare
   
   
   • This includes the Intel DMI 2.0 Service Provider and TIRPC server.
   • A local (RPC-less) client is included for Component Interface (CI) and local Management Interface (MI) support.
   
   
2. DMI 2.0 ONC RPC Client for Windows*
   
   
   • Provides remote Management Interface (MI) support including indications, through ONC RPC.
   
   
3. DMI 2.0 SDK Support, specific to NetWare
   
   
   • DMI 2.0 local Management Interface (MI) API
     This includes import (*.imp) and header files.
   • DMI 2.0 local Component Interface (CI) API
     This includes import (*.imp) and header files.
   • Documentation
     This includes an SDK reference manual.
   2. Target Environments
   ----------------------------------
   
   
   • The NetWare Service Provider runs on Novell NetWare and IntranetWare* versions 4.10 and 4.11, respectively.
   • TIRPC must be installed on the server in order for it to be accessible from a remote system. See Section 6.2 for information on how to obtain and install TIRPC.
   • The DMI 2.0 ONC Client runs on Windows NT* versions 3.51 and 4.0, Windows 95 and OSR2.
   
   3. Technical Support Information
   -----------------------------------------------
   
   See the support information page.
   
   4. Installation Instructions
   ---------------------------------------------
   
   Download the self-extracting installation file, then follow the instructions on the screen.

   Note: You will be prompted twice to enter a target directory; the first directory is for the ONC Client component, the second is used as a map to the NetWare Server where the Service Provider will be installed.

   For Windows NT, you must be logged into an account with administrator privileges to install the ONC Client in this SDK.

   For NetWare, you must have a mapping to the SYSTEM directory and rights to read, write and create files. This generally requires administrator or supervisor privileges.

   NetWare files are copied to a single server per installation.

   SDK Installation Known Problems / Issues

   • If the installation program finds a previous or an old copy of the DMI SDK, it does not allow the user to choose the target directory for the ONC client. Instead, it uses the old one.

     Workaround
     Reinstall the Win32 client in the requested directory and reinstall the NetWare SDK. Please note that if you have a full Win32 SP installation, you will have to reinstall it, too.

   • In Windows NT, the installation program fails to move client files that are currently in use from an old installation to a backup directory. This causes the installation program to stop the installation process with an appropriate warning message. This problem applies only if you try to reinstall the SDK and the target installation directory is located on a drive that is different than the current installation's drive.

     Workaround
     Stop the Service Provider service and its clients manually, or use the same target directory.

   • In Windows 95, the installation program fails to move client files that are currently in use from an old installation to a backup directory. This causes the installation program to stop the installation process with an appropriate warning message. This problem applies only if you try to reinstall the SDK.

     Workaround
     Stop the Service Provider and its clients manually.

   • If the installation process is canceled while files are being copied, some files remain from the old installation while others are updated. This may prevent the previously-installed SDK from running.

     Workaround
     Don't cancel the installation process during the file copy phase.

   • The installation program may leave some temporary files in the temp directory. The temporary files are located in %temp%\~pftw???\*.* and %temp%\_istmp??.dir\*.* For example:
     c:\temp\~pftw001\setup.ins and c:\temp\_istmp1.dir\_isdel.exe

     Workaround
     Remove those files manually after reboot.

   SDK uninstall procedure

   To uninstall the SDK, click the Uninstall icon in the Intel DMI 2.0 NWSP SDK v1.0 (or the user-designated) program folder or use the remove program in the Add/Remove icon located in the Control Panel. After you complete the uninstall process, reboot your computer.

   SDK UnInstall Known Problems / Issues

   • The uninstall program tries to delete the NetWare Service Provider files. It looks for them in the same drive letter and directory that was used for installation. Note that if this drive letter is now mapped to another server, the uninstall program tries to delete files on the other server.

     Workaround
     Use the same map letter as in the original installation. If you do not want your NetWare Service Provider files deleted, either unmap the SYSTEM directory or log in as a non-privileged user. You can use this option only if you want to uninstall the client software.

   • The installation program adds some lines to the AUTOEXEC.NCF file but the uninstall program does not remove them.

     Workaround
     Edit the AUTOEXEC.NCF file and manually remove any unnecessary lines.
     
     

   5. Operating Instructions
   -----------------------------------
   
   The Installation procedure creates the Intel DMI 2.0 NWSP SDK v1.0 (or the user-designated) program folder. This folder will contain the uninstallation icon and icons for the documentation.

   If the DMI 2.0 ONC Client is selected during installation, the <selected path>\bin directory is added at the beginning of the Path environment variable (where <selected path> is the installation directory).

   If the NetWare Service Provider is selected during installation, an additional screen appears, prompting for the path to the NetWare SYSTEM directory. Service Provider files are copied to the selected mapping (the SP location on the NetWare Server is fixed; it is always SYS:SYSTEM), and the AUTOEXEC.NCF file is modified to launch the Service Provider at startup.
   
   6. Product Release Notes
   ------------------------------------------
   
   

   1. DMI 2.0 Service Provider SDK Reference Manual, NWREFMAN.PDF

      Adobe Acrobat* Reader version 3.0 or greater is required to view this file. The viewer is available at no cost from Adobe.

      When opening this document in Adobe Acrobat Reader, the default magnification causes some graphics to degrade. For optimal viewing, select the Zoom In option from the View menu and set the magnification to 160%.

   2. Transport Independent RPC (TIRPC)

      Notes for NetWare servers version 4.10

      The TIRPC can be found in Novell's LAN WorkShop SDK CD or TIRPC toolkit. The LAN WorkShop installation program fails to install the TIRPC from the SDK CD; instead, you have to install it from three floppy disks. Novell provides a utility that converts the TIRAP files on the CD to three floppy disks. This utility can be found in the Novell knowledge base on the Web at http://support.novell.com. Click Search on the top bar and then search for SDKDSK. Once you create the disks, follow Novell's instructions.

      The TIRPC must be loaded by the RPCSTART.NCF; it should not be autoloaded. To ensure this, the RPCSTART.NCF line in the AUTOEXEC.NCF file must appear before any line loading an NLM that autoloads TIRPC.

      Verify that the TLI.NLM version is 4.10a, not 4.10. The TLI.NLM 4.10a is part of Novell patch STRLT4.EXE.

      The DMI 2.0 Service Provider SDK for NetWare installation program determines the version of NetWare by looking for the CLIB.NLM version. If you have CLIB.NLM version 4.11 in a NetWare 4.10 server or vice versa, then an incorrect version of TIRPC.NLM remains in the SYSTEM directory.

      TIRPC NLM file versions for NetWare 4.10

      These TIRPC files must be located in the SYS:SYSTEM directory of the NetWare server:

      TIRPC.NLM	1.10a	August 20, 1993
      NETDIR.NLM	1.10a	August 20, 1993
      LOCAL_ND.NLM	1.10a	August 20, 1993
      TCP_ND.NLM	1.10a	August 20, 1993
      SPX_ND.NLM	1.10a	August 20, 1993
      RPCBSTUB.NLM	1.10a	August 20, 1993

      Notes for NetWare servers version 4.11

      The TIRPC is part of the NetWare/IP 2.20 Server Software optional product. To install this product, type LOAD INSTALL at the server console, then select Product options. Next, select Choose an item or product listed above, then Install NetWare IP and follow the instructions.

      The file SPX_ND.NLM is not included in the above product, so you must download it from this Novell support Web site: http://support.novell.com. Click File Finder at the top of the page, then look for the SPX_ND filename. After the download, add the following two lines to the SYS:ETC\RPCNET.CFG file on your server:

      spx tpi_cots v netware spx /dev/nspx sys:/system/spx_nd.nlm
      ipx tpi_clts v netware ipx /dev/nipx sys:/system/spx_nd.nlm

      Add the following line to the SYS:SYSTEM\UNISTART.NCF file, just before the load tcp_nd line:

      load spx_nd

      UNISTART.NCF must load the TIRPC. Do not autoload it. To ensure this, the UNISTART.NCF line in the AUTOEXEC.NCF file must appear before the line containing load nwip name=NWIP_1, or any line loading an NLM that autoloads TIRPC.

      The file TIRPC.NLM will be replaced by the DMI 2.0 NetWare SDK installation program.

      The DMI 2.0 NetWare SDK installation program determines the version of NetWare by looking for the CLIB.NLM version. If you have CLIB.NLM version 4.10 in a NetWare 4.11 server or vice versa, then an incorrect version of TIRPC.NLM remains in the SYSTEM directory.

      TIRPC NLM file versions for NetWare 4.11

      The following TIRPC files must be located in the SYS:SYSTEM directory of the NetWare server:

      NETDIR.NLM	1.10c	September 22, 1994
      LOCAL_ND.NLM	1.10b	July 6, 1994
      TCP_ND.NLM	1.10b	July 6, 1994
      SPX_ND.NLM	1.10b	July 6, 1994
      RPCBSTUB.NLM	3.04k	June 12, 1995

      The installation program for this SDK copies this file:

      TIRPC.NLM

      1.10y

      February 7, 1995

   3. DMI 2.0 Service Provider v2.54 (NWSL.NLM version 2.54, NWDMI2.NLM version 2.54, ONCSP.NLM version 2.54a)

      Known Issues

      • DMI Service Provider Database (SLDB.DMI) is not compatible with v1.x databases. Database upgrade is not implemented in this version of the Service Provider.

      • The Service Provider database does not support variables of size greater than 508 bytes. CI-instrumented attributes do not have this limitation.

      • The Service Provider detects duplicate keys in a table at installation time; that is, you cannot install a MIF with a table that contains two rows with the same keys. However, the Service Provider does not check for this condition when the value of a key is set.

      • The Service Provider does not allow more than 127 keys per group.

      • The Service Provider doesn't guarantee synchronization between indication and completion of DMI Add / Delete operations for Component, Language and Group entities; that is, an application may receive a DmiComponentAdded indication before DmiAddComponent function completion.

      • The Service Provider serializes requests to the component instrumentation on a per-component(Id) basis. This means that an instrumentation application that registers for multiple components may receive overlapping calls. It is the responsibility of the application to serialize calls across component boundaries, as needed.

      • The Service Provider delivers pending indications even after the event consumer has canceled indication subscription. For example, System B registers to receive indications from System A. After System B unregisters and unsubscribes from System A, System B will still receive all outstanding indications (any indications that are "waiting" when the unregister occurs) from System A, but no additional indications. To avoid this situation, ensure that no indications are pending before canceling indication subscriptions, if possible.

      • The DmiGetSubscriptionAddress() helper function may return an address that the indications originator cannot reach. This can occur only on machines with more than one IP address, when one of these addresses is unreachable from the indications originator machine. For example: Managed System A has IP address 143.185.63.176, and console System B has two IP addresses: 143.185.63.172 and 192.16.57.230. System A can communicate with System B through 143.185.63.172, but it can't communicate through the second IP address (192.16.57.230). DmiGetSubscriptionAddress can return only one of these addresses, which in some cases is the one that System A cannot access.

        Possible workarounds:

        1. Provide connectivity to all client addresses.

        2. In the case where the client has more than one IP address, it can provide by itself the right IP address for the subscription without calling the DmiGetSubscriptionAddress() function. This workaround can be used only if you have a single indication RPC server running on your system (single management application).

           For example: Client System B has two IP addresses, 143.185.63.172 and 192.16.57.230. Instead of calling to the DmiGetSubscriptionAddress() function, you can subscribe with the right IP address, that is, 143.185.63.172. (In this case, you don't have to provide an end point. Since you don't provide an end point, only one indication server per system will receive the indications.)

      • In Windows 95 without a NetWare client, it is not possible to do a remote registration using an explicit NetWare server name; instead, you have to provide a full IPX address as an RPC address. An attempt to use the NetWare server name will result in a "Service provider is inactive" error (0x211).

      • Due to TIRPC limitations on the server side, the NetWare Service Provider can service only up to 62 simultaneous remote registrations (the number of local registrations is limited only by available memory). If a client attempts a remote registration and this limit is surpassed, the remote registration will fail with error DMIERR_RPC_COMM_FAILURE (0x500).

      • If the ONCSP nlm is unloaded after the simultaneous remote registration limit is exceeded, then various memory and resource leaks will be reported. You can ignore these reports.

      • The MIF parser does not check <DATE> value format validity while installing a new component, group or language mapping. However, DmiSet commands do check <DATE> value format.

      • The DMI Service Provider's database grows with the addition of each new element (Component, Language, Group or Row); however, this space is not recovered when deleting these elements. To recover this space, invoke the Service Provider, NWSL.NLM, with the shrink command line option (-r). Note that database access time may increase as its size grows.

      • The DMI Specification Version 2.00 states that the Subscriber Address can be up to 1024 characters. Since the Service Provider database does not support variables greater than 508 bytes, the Subscriber Address size has been limited to 508 bytes in the SP MIF (NWSL.MIF).

      • The SP does not permit the installation of MIF files that contain group and/or attribute IDs equal to -1.

      • National Language Support in the Service Provider:
        1. The only translatable strings are meta-strings: names, descriptions, pragmas and enumerations. DmiList commands return strings in the session language, if possible, or in the component default language with return code DMIERR_DEFAULT_LANGUAGE_RETURNED.

           Note: Previous versions of the Service Provider may return an invalid number of terminating nulls in the string if the session language is not found.

        2. Attribute values (keys and non-keys) are encoded in the default (first) language of the component. Component instrumentation may support more than one language encoding; however, only the default language is requested by the SP for each component. In this way, the SP ensures that static and dynamic attribute values have the same encoding. All requests to get/set attribute value return/change the only instance of the attribute.

        3. The SP does not check DisplayStrings for language encoding compliance. The iso8859-1 string should be terminated with one zero byte; unicode strings have an even number of bytes, the last two of which are zeros. It is the management application's responsibility to ensure proper encoding of input parameters.

        4. The SP modifies strings passed between DMI 1.0 and DMI 2.0 entities. It adds/removes a null character based on the default language encoding of the component.

        5. The default session language is en|US|iso8859-1. A management application can change the session language, using the DmiSetConfig function. It is possible to call this function with a partial language string. In this case, the SP fills in all missing fields from the en|US|iso8859-1 language string.
      
      
      
      * Legal Information © 1998 Intel Corporation